在 Scrum Guide 中其實並沒有明確地提到所謂的「精鍊會議」( Refinement) ，因此在社群中對「精鍊會議」和 「計畫會議」( Planning) 討論沒少過。也正是這種模糊的美，造就了許多團隊的迷糊。我經歷過的團隊，起初都是把有關使用者故事的討論，放在 Planning 會議中。在會議中的活動包含：

• 審閱 UI / UX 規格
• RD 們討論實作細節
• 估點
• 給出 Sprint 產出的承諾 ( Commitment)

乍看之下，都很合理，但實際執行起來，每個團隊都遇到了同樣的問題：

• UI / UX 有問題時，設計師會在 Sprint 開跑後才能給出定稿，導至 RD 開發排程受影響
• 對於還沒有掌握度的技術， RD 們容易進入發散式的討論，進而估出非常大的故事點數
• 所有 RD 對故事進行估點，然後討論點數差異。而不同領域的 RD ，對自己不熟悉的實作進行估點，跟擲骰子沒什麼兩樣。

而這樣的 Planning 會議開下來，最糟的情況，可以開一整天。即使投資了大量的時間，卻因為未定的細節太多，RD 無法給出承諾，導至能交付的項目少得可憐。在這個 Planning 的結構中，張力-舒緩系統隨處可見。因此，我們需要一個新的結構/系統：
一個協助開發者可以高效產出的規畫系統

系統方塊圖如下：

在這個系統中，我明確的把 Refinement 從 Planning 中抽離，形成一個獨立的活動。這個概念來自「開腦 CSM」課程。 Daniel 老師是這樣論述：

「Refinement 是 Scrum 團隊的遠光燈，團隊在 Refinement 中應針對「未來」即將進行開發的 User Story 進行討論，而不該把討論放在一個已開跑的 Sprint。」

「提前討論的好處在於，PO/PM 與設計師有時間針對未周全的設計進行修改，工程師也可以針對掌握度不足的技術進行前置研究。」

「提前的時間以不超過 2 Sprint 為原則，隔太久，大家都忘了在 Refine 什麼。」

根據我的實務經驗，將 Refinement 提前進行，確實可以讓工程師在開發過程中，有明確的開發方向，並減少因規格不明或技術掌握度問題帶來的阻礙，因此可以推論開發效率也獲得提升。

至於如何提出效率提升的量化指標，我採用問卷評分方式，針對 30 個 Scrum 團隊成員進行調查，題目為：

對於轉型前/後的開發流程，1 - 10 分你各會給予幾分？

結果如下圖：

這個調查顯示轉型前的團隊評分偏低，間接說明團隊存在不小的內部張力。而經過調整之後，對於開發流程的滿意度明顯是往好的方向移動。

我提出的系統肯定不是完美的，但這裡的重點是：與團隊對話。透過有結構的對話，可以知道團隊的感受，並且也搜集團隊的意見，再注入系統中，我們終究可以打造出最合適個別團隊的開發系統。有關問題設計與提問技巧，留到後面一些再與大家分享。

接下來的文章，我們將逐步拆解規畫系統，以及每個環節的實踐方法，我們明天見！